Conversation
|
Commits Review LGTM |
|
Commits
Review LGTM |
|
Commits
Review LGTM |
418b930 to
2913356
Compare
|
Commits Review LGTM |
|
Commits
Review
|
4f8bb6c to
12aa42e
Compare
|
Commits
Review LGTM |
207262e to
db5e37b
Compare
|
Commits
Review
|
db5e37b to
7e9de81
Compare
|
Commits Review LGTM |
7e9de81 to
0477733
Compare
|
Commits Review LGTM |
0477733 to
6952f0e
Compare
|
Commits Review LGTM |
Initial data set
Oracle version: Oracle Database Express Edition (XE) Release 21c running in a container.
18,000,000 rows, roughly ~3GB
The below focuses on Streaming results as snapshotting provides a greater degree of concurrency and is far more well known between SQL based components as they'll have similar characteristics. In this instance I was seeing -140,000 msg/sec on a single table during snapshot.
LogMiner Streaming Results
Time taken: ~12 minutes
Average: ~50,000 msg/s (total average: 25,000 msg/s)
Peak: ~ 70,000 - 90,000 msg/s
Observations:
The highest throughput the connector appears to get is about 70-90,000 messages as second. Removal of the buffering improves things slightly, but not much. Proving that the limitation comes from how quick we can fetch data from LogMiner.
I performed a quick test with Debezium and its OracleCDC component that also uses LogMiner and was seeing similar results, though more thorough testing would need to be done.
Given LogMiner was never designed for the purposes of CDC and as a result has a number of performance characteristics that are always going to impede its throughput such as:
COMMITor aROLLBACKis received before flushing